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In order to maintain control of the contents of Apollo Guidance Computer Flight 
Programs, there are four (4) forms that are used to authorize changes to a 
program or the specification. Each form has its own unique function. The fol- 
lowing is a description of that function and how the form is employed in the 
overall system of controlling program and/or specification content. 

I. Program Change Request (PCR ) 

A Program Change Request (PCR) is a request submitted by 
the originator to change the specification (GSOP) as indicated on the 
PCR form for the reasons listed. PCRs go through several steps from 
the time of origin to final approval by NASA for implementation. For 
a detailed description of this flow, see E-2345, "Software Configuration 
Management Plan. " 

II. Program Change Notice (PCN) 

A Program Change Notice (PCN) is similar to a PCR except 
that a PCN is a notice of a change being made to the specification 
(GSOP) and not a request for a change as in the case of a PCR. A 
PCN is utilized for notification of clerical corrections, or a notifica- 
tion that a change is to be incorporated into the specification without 
which further program development could not proceed. As can be 
seen by the definition above, a PCN is employed as a fast preliminary- 
authorization and notification of a mandatory change or clerical correc- 
tions prior to approval by the formal Software Change Control Board 
(SCB). The MIT/IL Project Managers shall inform the NASA/FSB 
Program Engineers of PCNs being implemented. The use of PCNs to 
authorize changes has some risk involved in that formal SCB action 
might be to "disapprove" the PCN which then would require undoing 
all that had been authorized by the change. For this reason, the 
number of PCNs should be kept to a minimum. 
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III. Anomalies 

"Anomalies" are a report of deviation in expected performance, 
program irregularities or amplifications arising out of testing and 
inspection after program release (Level 6 testing). Such anomalies are 
controlled by submitting to MSC/FSB a detailed description of the 
anomaly, its causes and effect and recommendations for effective action. 
The disposition of anomalies is usually to fix in the next program 
release and write a program note for the program that contains the 
anomaly. When the decision is made to fix the anomaly in a program, 
the authorization may be given in one of two ways: 

1. If the anomaly has no affect on the GSOP, then a routing 
slip is attached to the anomaly with direction to fix the 
anomaly. 

2. If the anomaly has GSOP impact, then a PCR (in some 
cases, a PCN) is prepared and processed in the normal 
manner and the PCR is the authorization to fix the GSOP 
and the program. 

IV . Assembly Control Board Request (ACB ) 

The Assembly Control Board Request (ACB) is used internally 
within MIT/IL to authorize changes to the assembly that are not speci- 
fied in the GSOP or considered an anomaly. ACBs are utilized to 
conserve coding, thus providing additional room for other authorized 
changes, to improve program efficiency, etc. ACBs require the 
approval of the Mission Program Development Director (M. Hamilton) 
prior to implementation and are reviewed by the Colossus or Luminary 
Project Manager (S. Copps/R. Larson) upon receipt of their copy, 

V. General 

PCRs, PCNs and Anomalies are distributed internally at MIT/IL 
for information purposes before the final decision to implement has been 
determined. Care should be exercised to prevent premature implementa- 
tion before authorization has been received. PCRs, PCNs and Anomalies 
should not be implemented into the coding or the GSOP until a copy of the 
PCR, PCN or Anomaly is received with a routing slip attached, reviewed 
by the Mission Program Development Director (M. Hamilton) and signed 
by the Colossus or Luminary Project Manager (S. Copps/R. Larson), 
authorizing implementation. 
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